home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0273.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.1 KB  |  73 lines
  1. I think there's something that people are missing in this discussion
  2. that is basic to the MIME philosophy, so here comes my two cents:
  3.  
  4. MIME is a standard with a very different philosophy from many other
  5. standards (ODA, etc.).  It has been said, not entirely incorrectly, that
  6. MIME isn't a format standard at all, but rather a standard for labeling
  7. and safely encoding data whose format is described by other standards. 
  8. (Indeed, I think a major reason that text/richtext is the most
  9. controversial content-type is that it almost is the ONLY MIME type of
  10. which this is not true.)  The basic idea of putting the minimum possible
  11. information in the header field is a natural outgrowth of this
  12. philosophy, hence the argument that if the information is in the body,
  13. it should not be duplicated in the headers.  
  14.  
  15. Larry Masinter has pointed out -- quite correctly -- that there are
  16. situations in which this is undesirable.  I find his anonymous ftp
  17. example quite compelling:  I would prefer not to ftp a 50 megabyte file
  18. only to find out that it is the wrong kind of postscript.  I don't
  19. think, however, that requiring a "full" description of the detailed
  20. format information is necessarily the right solution, largely because
  21. defining "full" for any given format is so problematic, and runs the
  22. danger of being inconsistent with the internal information.
  23.  
  24. Another part of the MIME philosophy is openness and extensibility.  This
  25. openness, I believe, points the way to a more appropriate resolution of
  26. the problem.  It is worth noting that the MIME standard does not close
  27. the book on additional parameters in the content-type line.  That is,
  28. MIME says that a PostScript body part should be labelled as
  29.  
  30. Content-type: application/postscript
  31.  
  32. It also says, I believe, that unrecognized parameters should be ignored.
  33.  This means that a MIME-conformant implementation will treat the above
  34. content-type and the following one as equivalent:
  35.  
  36. Content-type: application/postscript; foo=bar; FavoriteCheese=muenster
  37.  
  38. Not a very useful example, I'll admit.  But this opens the door for
  39. communities to experiment with what additional parameters might be
  40. useful.  If the wais, gopher, or www communities decided to use MIME as
  41. the base data representation standard, they could easily specify a few
  42. additional parameters for situations of concern to those communities. 
  43. Indeed, as has been pointed out, if the transport system is other than
  44. mail, there are likely to be some diffferent concerns.  (Larry's
  45. anonymous ftp problem, for example, is arguably central to wais and
  46. relatively peripheral to email.)   So it might simply prove to be more
  47. important to the wais community to have the Postscript Level labeled in
  48. the header data than it was to the mail community.  No big deal.  The
  49. consensus in the mail community (at least as reflected on the ietf-822
  50. mailing list, which devised MIME) was that such a parameter was not
  51. particularly necessary or desirable for email use.  The WAIS community
  52. might reach a diametrically opposite conclusion, and can accordingly
  53. extend MIME to include a few extra parameters, content-types, etc.  The
  54. most useful of these, I conjecture, will eventually find their way back
  55. into the email world.  This kind of evolution is precisely the reason I
  56. always felt so strongly that MIME needed a path for graceful evolution,
  57. including the IANA process for registering new content-types, character
  58. sets, and parameters.
  59.  
  60. So the bottom line for me is that Larry's concerns have definite merit,
  61. but I think that they can easily be accomodated as minor extensions to
  62. MIME.  My suggested path for making those extensions is to first try to
  63. reach a consensus on what extensions are needed for the wais/www/gopher
  64. communities, and then register those extensions with IANA.  If any of
  65. them prove to be problematic in the sense that they need to be
  66. universally implemented -- as opposed to only being implemented among
  67. cooperating software -- the documents defining them can be submitted to
  68. the IAB standardization process.  However, I suspect that official
  69. standard status will not be necessary in most cases.
  70.  
  71. I hope that sheds some light on muddy waters...   -- Nathaniel
  72.  
  73.